UMTS (Universal Mobile Telecommunications System) is the 3G (3rd Generation) mobile communication system standardized by 3GPP (3rd Generation Partnership Project). The 3GPP launched a study item “Evolved UTRA and UTRAN” better known as “Long Term Evolution (LTE)”. The study investigates means of achieving major leaps in performance in order to improve service provisioning, and to reduce user and operator costs. In view of these studies and in order to enable interworking with other radio access technologies, the need arose for the definition of a new Evolved Packet Core (EPC) network. For further details, please see 3GPP TS 23.401, “General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access”, version 8.3.0 and 3GPP TS 23.402, “Architecture enhancements for non-3GPP accesses”, version 8.3.0, both documents available at http://www.3gpp.org and incorporated herein by reference.
An exemplary representation of the E-UTRAN architecture of LTE is shown in FIG. 1. In the following, the most important entities in this architecture are explained to facilitate a better understanding of the invention described herein.
The E-UTRAN consists of evolved Node Bs (eNBs or eNode Bs), providing the E-UTRA user plane (PDCP/RLC/MAC/PHY) and control plane (RRC) protocol terminations towards the mobile node. The eNodeB hosts the Physical (PHY), Medium Access Control (MAC), Radio Link Control (RLC), and Packet Data Control Protocol (PDCP) layers that include the functionality of user-plane header-compression and encryption. It also offers Radio Resource Control (RRC) functionality corresponding to the control plane. It performs many functions including radio resource management, admission control, scheduling, enforcement of negotiated UL QoS, cell information broadcast, ciphering/deciphering of user and control plane data, and compression/decompression of DL/UL user plane packet headers.
The eNode Bs are interconnected with each other by means of the X2 interface. The eNode Bs are also connected by means of the S1 interface to the EPC (Evolved Packet Core), more specifically to the MME (Mobility Management Entity) by means of the S1-MME and to the Serving Gateway (S-GW) by means of the S1-U. The S1 interface supports a many-to-many relation between MMEs/Serving Gateways and eNode Bs.
The Serving Gateway routes and forwards user data packets, while also acting as the mobility anchor for the user plane during inter-eNodeB handovers and as the anchor for mobility between LTE and other 3GPP technologies (terminating the S4 interface and relaying the traffic between 2G/3G systems and PDN-GW). For idle state UEs, the Serving Gateway terminates the downlink data path and triggers paging when downlink data arrives for the UE. It manages and stores UE contexts, e.g. parameters of the IP bearer service, network internal routing information. It also performs replication of the user traffic in case of lawful interception.
The MME is the key control-node for the LTE access-network. It is responsible for idle mode UE tracking and paging procedure including retransmissions. It is involved in the bearer activation/deactivation process and is also responsible for choosing the Serving Gateway for a UE at the initial attach and at time of intra-LTE handover involving Core Network (CN) node relocation. It is responsible for authenticating the user (by interacting with the Home Subscriber Server, HSS). It checks the authorization of the UE to camp on the service provider's Public Land Mobile Network (PLMN) and enforces UE roaming restrictions. The MME is the termination point in the network for ciphering/integrity protection for Non-Access Stratum (NAS) signaling and handles the security key management. The MME also provides the control plane function for mobility between LTE and 2G/3G access networks with the S3 interface terminating at the MME from the SGSN (Serving GPRS Support Node). The MME also terminates the S6a interface towards the home HSS for roaming UEs.
The Packet Data Network Gateway (PDN-GW) provides connectivity for the UE to external packet data networks by being the point of exit and entry of traffic for the UE. A UE may have simultaneous connectivity with more than one Packet Data Network Gateway for accessing multiple Packet Data Networks (PDNs). The Packet Data Network Gateway performs policy enforcement, packet filtering for each user, charging support, lawful Interception and packet screening. Another key role of the Packet Data Network Gateway is to act as the anchor for mobility between 3GPP and non-3GPP technologies.
To summarize the architecture depicted in FIG. 1, the new 3GPP Core Network is mainly separated into three logical entities in order to support the new E-UTRAN access. In the user plane, the Packet Data Network Gateway (PDN-GW) is the gateway to the external networks and the global mobility anchor for mobility between 3GPP and non-3GPP access technologies (for example, COMA 2000, WiMAX or WIFI). Also in the user plane, the Serving Gateway can be considered the mobility anchor for mobility between 3GPP accesses (E-UTRAN, UTRAN, GERAN). The Mobility Management Entity (MME) is the control plane entity responsible for the mobility management of UEs (also referred to in the following as mobile terminals, mobile nodes or MNs) moving between different E-UTRAN base stations (eNode Bs) and for the session management.
Another aspect of LTE is the support of 3GPP accesses (e.g. GERAN, UTRAN, E-UTRAN), non-3GPP accesses (e.g. WLAN, WiMAX, 3GPP2, etc.) and mobility between those different types of access, i.e. in a heterogeneous network. The anchor for the mobility between the 3GPP and the non-3GPP accesses is a Packet Data Network Gateway that also provides the interface to the external Packet Data Networks. The mobility between 3GPP and non-3GPP accesses is based on Mobile IP—the protocol used can be either Client Mobile IP (see Johnson et al., “Mobility Support in IPv6”, IETF RFC 3775, June 2004 and Soliman et al., “Mobile IP6 Support for Dual Stack Hosts and Routers”, IETF Internet Draft, draft-ietf-mext-neuro-v4traversal-06.txt, November 2008, both documents available at http://www.ietf.org and incorporated herein by reference) or Proxy Mobile IP (see Gundavelli et al., “Proxy Mobile IPv6”, IETF RFC 5213, August 2008 and Leung et at, “WiMAX Forum/3GPP2 Proxy Mobile IPv4”, IETF Internet Draft, draft-leung-mip4-proxy-mode-09.txt, July 2008, both documents available at http://www.ietf.org and incorporated herein by reference).
The non-3GPP accesses (access networks) can be classified into trusted access networks and untrusted access networks. The assumption for untrusted access networks is that a UE in an untrusted access network first needs to establish a secure tunnel (based on IPsec—see Kent et al, “Security Architecture for the Internet Protocol”, IETF RFC 4301, December 2005, available at http://www.ietf.org and incorporated herein by reference) to an evolved Packet Data Gateway (ePDG) before being able to access operator services, i.e. the PDN. The ePDG is similar to the PDG used for Interworking WLAN (see 3GPP TS 23.234, “3GPP system to Wireless Local Area Network (WLAN) interworking; System description”, version 7.7.0, available at http://www.3gpp.org and incorporated herein by reference). In trusted accesses no secure tunnel is needed, instead the PDN-GW may be directly accessed from the UE.
For mobility within the same or between different non-3GPP accesses similar mechanisms can be used as for mobility between 3GPP and non-3GPP accesses, i.e. Client or Proxy Mobile IP.
When a UE is connected to a network, it has connectivity to at least one Packet Data Network and may be also connected to multiple Packet Data Network s concurrently. Possible PDNs are for example the public internet, corporate network, IMS/SMS network.
When a UE, connected to at least one Packet Data Network, wants to perform a handover to an untrusted non-3GPP access network the UE must first discover an ePDG from the non-3GPP access using the allocated local IP address. For this, the UE discovers/selects an ePDG by either static configuration in the UE or dynamically. With dynamic discovery if the UE roams in a VPLMN (Visited Public Land Mobile Network), it constructs an FQDN (Fully Qualified Domain Name) using the VPLMN ID and requests the DNS system. Otherwise, the UE constructs an FQDN using the HPLMN ID (HPLMN=Home Public Land Mobile Network) and uses a DNS query to resolve an ePDG address. Subsequently, the UE selects an ePDG address from the list returned and initiates IKE/IPSec tunnel establishment (see Kaufman, “Internet Key Exchange (IKEv2) Protocol”, IETF RFC 4306, December 2005; available at http://www.ietf.org and incorporated herein by reference) to this ePDG. If the IKE/IPsec tunnel is set up, the UE can send and receive user data for the PDN connection. However, the IKEv2/IPsec tunnel establishment is quite time consuming because of the key creation. Therefore, in order to allow faster handover to the untrusted non-3GPP accesses, the UE should discover the ePDG and establish the secure tunnel before doing the handover using the existing connection to a Packet Data Network and the associated home IP address.
Depending on the network configuration, there can be several candidate ePDGs the UE may connect to in advance, but some of them may not be reachable from a new access or may not be optimal in sense of routing efficiency. Therefore, in order to avoid maintaining states to several ePDGs for a long time, the UE should pre-establish the IKE/IPSec tunnel with the ePDG shortly before the handover to the untrusted non-3GPP access is initiated.
One problem that may occur when the UE wants to perform pre-establishment with a target ePDG is that the ePDG is not reachable from the existing PDN connection (see FIG. 2), neither via the PDN-GW nor via the Packet Data Network. This may for example happen due to access restrictions that the Packet Data Network (e.g. corporate network or IMS/SMS network) does not allow to connect to an external network, i.e. an ePDG, or in case of handover with PDN/PDN-GW/IP-address change that the ePDG is not reachable from the new connection.
Further, the UE may not know whether the ePDG is reachable from any of the PDNs the UE is connected to and the detection of ePDG unreachability may increase signalling load (e.g. for bearer creation for reachability test), may take time and thus increase handover delay.
The delay may even take minutes, because according to the procedure described in the 3GPP TS 23.402, section 7.2.1 and 7.3, the UE sends an IKE_SA_NIT message to the ePDG and if the ePDG is not reachable either no response is received or an ICMP destination unreachable may be received. The IKEv2 standard suggests to retransmit requests over a period of several minutes and also “[ . . . ] an endpoint MUST NOT conclude that the other endpoint has failed based on any routing information (e.g., ICMP messages) [ . . . ] an endpoint MUST conclude that the other endpoint has failed only when repeated attempts to contact it have gone unanswered for a timeout period [ . . . ] it is suggested that messages be retransmitted at least a dozen times over a period of at least several minutes before giving up on an SA” (confer section 2.4 of IETF RFC 4306).